home *** CD-ROM | disk | FTP | other *** search
/ Power Programmierung 2 / Power-Programmierung CD 2 (Tewi)(1994).iso / gnu / gnulib / rcs4 / doc / ci.man next >
Encoding:
Text File  |  1990-08-18  |  9.5 KB  |  331 lines
  1.  
  2.  
  3.  
  4.      CI(1L)             Purdue University            CI(1L)
  5.  
  6.  
  7.  
  8.      NAME
  9.       ci - check in    RCS revisions
  10.  
  11.      SYNOPSIS
  12.       ci [ options ] file ...
  13.  
  14.      DESCRIPTION
  15.       Ci stores new    revisions into RCS files.  Each    file name
  16.       ending in `,v' is taken to be    an RCS file, all others    are
  17.       assumed to be    working    files containing new revisions.     Ci
  18.       deposits the contents    of each    working    file into the
  19.       corresponding    RCS file.  If only a working file is given, ci
  20.       tries    to find    the corresponding RCS file in the directory
  21.       ./RCS    and then in the    current    directory.  For    more details,
  22.       see the file naming section below.
  23.  
  24.       For ci to work, the caller's login must be on    the access
  25.       list,    except if the access list is empty or the caller is
  26.       the superuser    or the owner of    the file.  To append a new
  27.       revision to an existing branch, the tip revision on that
  28.       branch must be locked    by the caller. Otherwise, only a new
  29.       branch can be    created. This restriction is not enforced for
  30.       the owner of the file, unless    locking    is set to strict (see
  31.       rcs(1L)).  A lock held by someone else may be    broken with
  32.       the rcs command.
  33.  
  34.       Normally, ci checks whether the revision to be deposited is
  35.       different from the preceding one. If it is not different, ci
  36.       either aborts    the deposit (if    -q is given) or    asks whether
  37.       to abort (if -q is omitted). A deposit can be    forced with
  38.       the -f option.
  39.  
  40.       For each revision deposited, ci prompts for a    log message.
  41.       The log message should summarize the change and must be
  42.       terminated with a line containing a single `.' or a
  43.       control-D.  If several files are checked in, ci asks whether
  44.       to reuse the previous    log message.  If the standard input is
  45.       not a    terminal, ci suppresses    the prompt and uses the    same
  46.       log message for all files.  See also -m.
  47.  
  48.       The number of    the deposited revision can be given by any of
  49.       the options -r, -f, -k, -l, -u, or -q.
  50.  
  51.       If the RCS file does not exist, ci creates it    and deposits
  52.       the contents of the working file as the initial revision
  53.       (default number: 1.1).  The access list is initialized to
  54.       empty.  Instead of the log message, ci requests descriptive
  55.       text (see -t below).
  56.  
  57.       -r[rev]   assigns the    revision number    rev to the checked-in
  58.             revision, releases the corresponding lock, and
  59.             deletes the    working    file. This is the default.
  60.  
  61.  
  62.  
  63.      Page 1                         (printed 8/18/90)
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.      CI(1L)             Purdue University            CI(1L)
  71.  
  72.  
  73.  
  74.             Rev    may be symbolic, numeric, or mixed.
  75.  
  76.             If rev is a    revision number, it must be higher
  77.             than the latest one    on the branch to which rev
  78.             belongs, or    must start a new branch.
  79.  
  80.             If rev is a    branch rather than a revision number,
  81.             the    new revision is    appended to that branch. The
  82.             level number is obtained by    incrementing the tip
  83.             revision number of that branch.  If    rev indicates
  84.             a non-existing branch, that    branch is created with
  85.             the    initial    revision numbered rev.1.
  86.  
  87.             If rev is omitted, ci tries    to derive the new
  88.             revision number from the caller's last lock. If
  89.             the    caller has locked the tip revision of a
  90.             branch, the    new revision is    appended to that
  91.             branch. The    new revision number is obtained    by
  92.             incrementing the tip revision number.  If the
  93.             caller locked a non-tip revision, a    new branch is
  94.             started at that revision by    incrementing the
  95.             highest branch number at that revision.  The
  96.             default initial branch and level numbers are 1.
  97.  
  98.             If rev is omitted and the caller has no lock, but
  99.             he is the owner of the file    and locking is not set
  100.             to strict, then the    revision is appended to    the
  101.             default branch (normally the trunk;    see the    -b
  102.             option of rcs(1L)).
  103.  
  104.             Exception: On the trunk, revisions can be appended
  105.             to the end,    but not    inserted.
  106.  
  107.       -f[rev]   forces a deposit; the new revision is deposited
  108.             even it is not different from the preceding    one.
  109.  
  110.       -k[rev]   searches the working file for keyword values to
  111.             determine its revision number, creation date,
  112.             state, and author (see co(1)), and assigns these
  113.             values to the deposited revision, rather than
  114.             computing them locally.  It    also generates a
  115.             default login message noting the login of the
  116.             caller and the actual checkin date.     This option
  117.             is useful for software distribution. A revision
  118.             that is sent to several sites should be checked in
  119.             with the -k    option at these    sites to preserve the
  120.             original number, date, author, and state.  The
  121.             extracted keyword values and the default log
  122.             message may    be overridden with the options -r, -d,
  123.             -s,    -w, and    -m.
  124.  
  125.       -l[rev]   works like -r, except it performs an additional co
  126.  
  127.  
  128.  
  129.      Page 2                         (printed 8/18/90)
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.      CI(1L)             Purdue University            CI(1L)
  137.  
  138.  
  139.  
  140.             -l for the deposited revision. Thus, the deposited
  141.             revision is    immediately checked out    again and
  142.             locked.  This is useful for    saving a revision
  143.             although one wants to continue editing it after
  144.             the    checkin.
  145.  
  146.       -u[rev]   works like -l, except that the deposited revision
  147.             is not locked.  This is useful if one wants    to
  148.             process (e.g., compile) the    revision immediately
  149.             after checkin.
  150.  
  151.       -q[rev]   quiet mode;    diagnostic output is not printed.  A
  152.             revision that is not different from    the preceding
  153.             one    is not deposited, unless -f is given.
  154.  
  155.       -ddate    uses date for the checkin date and time.  Date may
  156.             be specified in free format    as explained in    co(1).
  157.             Useful for lying about the checkin date, and for
  158.             -k if no date is available.
  159.  
  160.       -mmsg        uses the string msg    as the log message for all
  161.             revisions checked in.
  162.  
  163.       -nname    assigns the    symbolic name name to the number of
  164.             the    checked-in revision.  Ci prints    an error
  165.             message if name is already assigned    to another
  166.             number.
  167.  
  168.       -Nname    same as -n,    except that it overrides a previous
  169.             assignment of name.
  170.  
  171.       -sstate   sets the state of the checked-in revision to the
  172.             identifier state.  The default is Exp.
  173.  
  174.       -t[txtfile]
  175.             writes descriptive text into the RCS file (deletes
  176.             the    existing text).     If txtfile is omitted,    ci
  177.             prompts the    user for text supplied from the
  178.             standard input, terminated with a line containing
  179.             a single `.' or control-D.    Otherwise, the
  180.             descriptive    text is    copied from the    file txtfile.
  181.             During initialization, descriptive text is
  182.             requested even if -t is not    given.    The prompt is
  183.             suppressed if standard input is not    a terminal.
  184.  
  185.       -wlogin   uses login for the author field of the deposited
  186.             revision.  Useful for lying    about the author, and
  187.             for    -k if no author    is available.
  188.  
  189.      FILE NAMING
  190.       Pairs    of RCS files and working files may be specified    in 3
  191.       ways (see also the example section of    co(1)).
  192.  
  193.  
  194.  
  195.      Page 3                         (printed 8/18/90)
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.      CI(1L)             Purdue University            CI(1L)
  203.  
  204.  
  205.  
  206.       1) Both the RCS file and the working file are    given. The RCS
  207.       file name is of the form path1/workfile,v and    the working
  208.       file name is of the form path2/workfile, where path1/    and
  209.       path2/ are (possibly different or empty) paths and workfile
  210.       is a file name.
  211.  
  212.       2) Only the RCS file is given. Then the working file is
  213.       assumed to be    in the current directory and its name is
  214.       derived from the name    of the RCS file    by removing path1/ and
  215.       the suffix ,v.
  216.  
  217.       3) Only the working file is given. Then ci looks for an RCS
  218.       file of the form path2/RCS/workfile,v    or path2/workfile,v
  219.       (in this order).
  220.  
  221.       If the RCS file is specified without a path in 1) and    2),
  222.       then ci looks    for the    RCS file first in the directory    ./RCS
  223.       and then in the current directory.
  224.  
  225.      FILE MODES
  226.       An RCS file created by ci inherits the read and execute
  227.       permissions from the working file. If    the RCS    file exists
  228.       already, ci preserves    its read and execute permissions.  Ci
  229.       always turns off all write permissions of RCS    files.
  230.  
  231.      FILES
  232.       The caller of    the command must have read/write permission
  233.       for the directories containing the RCS file and the working
  234.       file,    and read permission for    the RCS    file itself.  A    number
  235.       of temporary files are created.  A semaphore file is created
  236.       in the directory containing the RCS file.  Ci    always creates
  237.       a new    RCS file and unlinks the old one.  This    strategy makes
  238.       links    to RCS files useless.
  239.  
  240.      DIAGNOSTICS
  241.       For each revision, ci    prints the RCS file, the working file,
  242.       and the number of both the deposited and the preceding
  243.       revision.  The exit status always refers to the last file
  244.       checked in, and is 0 if the operation    was successful,    1
  245.       otherwise.
  246.  
  247.      IDENTIFICATION
  248.       Author: Walter F. Tichy, Purdue University, West Lafayette,
  249.       IN, 47907.
  250.       Revision Number: 1.3 ; Release Date: 89/05/02    .
  251.       Copyright c 1982, 1988, 1989 by Walter F. Tichy.
  252.  
  253.      SEE ALSO
  254.       co(1L), ident(1L), rcs(1L), rcsdiff(1L), rcsintro(1L),
  255.       rcsmerge(1L),    rlog(1L), rcsfile(5L)
  256.       Walter F. Tichy, "Design, Implementation, and    Evaluation of
  257.       a Revision Control System," in Proceedings of    the 6th
  258.  
  259.  
  260.  
  261.      Page 4                         (printed 8/18/90)
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.      CI(1L)             Purdue University            CI(1L)
  269.  
  270.  
  271.  
  272.       International    Conference on Software Engineering, IEEE,
  273.       Tokyo, Sept. 1982.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.      Page 5                         (printed 8/18/90)
  328.  
  329.  
  330.  
  331.